AI 组件 Diff 生成：先对齐语义，再对齐代码

AI 组件 Diff 生成先对齐语义再对齐代码一、组件 Diff 不是把两段 JSX 做文本找不同AI 辅助前端开发里一个常见需求是“帮我解释这个组件改了什么”。如果只是把旧代码和新代码扔给模型让它写一段总结结果往往很像流水账新增了某个 props修改了某个 className删除了一段判断。看起来完整但对 Review 没多大用。真正有价值的组件 Diff要回答语义问题状态来源变了吗渲染分支变了吗事件副作用变了吗可访问性和性能有没有风险。代码文本变化只是表面组件行为变化才是重点。别让 AI 把 Review 写成“找不同小游戏”的解说词。二、先抽组件语义再生成变更说明可以把组件 Diff 分成结构解析、语义抽取、风险识别和说明生成。模型适合做归纳但前面的结构化信息不能偷懒。flowchart TD A[旧组件] -- C[AST 解析] B[新组件] -- C C -- D[Props 和 State Diff] C -- E[渲染分支 Diff] C -- F[副作用 Diff] D -- G[风险规则] E -- G F -- G G -- H[AI 生成 Review 摘要]如果没有 AST 层模型很容易被格式化差异骗到。换行、排序和重命名不该抢走真正风险的注意力。三、用结构化 Diff 约束模型输入下面示例表达一个简化的组件 Diff 结构。模型拿到的是这个结构而不是整段代码。type ComponentDiff { propsAdded: string[]; propsRemoved: string[]; stateChanged: string[]; effectsChanged: string[]; renderBranchesChanged: number; }; function hasBehaviorRisk(diff: ComponentDiff) { return diff.stateChanged.length 0 || diff.effectsChanged.length 0 || diff.renderBranchesChanged 0; }这类结构能让 AI 摘要更聚焦。比如“改了 UI 文案”与“改了 useEffect 依赖”不是一个级别的变更Review 说明里权重也不该一样。四、Diff 摘要要服务 Review 决策好的摘要应该告诉 Reviewer 先看哪里。比如“本次变更新增了异步请求副作用请重点检查取消逻辑和错误边界”。这比“修改了 useEffect”有用得多。还要标出低风险变更。纯样式类名调整、文案替换、测试快照更新可以合并到低风险列表。Review 时间有限AI 不该把所有变化都讲成同样重要。最后Diff 结果要可追溯。AI 说有风险旁边必须能定位到代码位置和规则来源。没有定位的建议像在会议里拍桌子很响但不好用。还要处理组件重命名。很多 Diff 工具看到文件名变化就当成删除和新增AI 也会跟着乱总结。可以通过导出名、相似 AST 和测试 ID 判断是否为同一组件演进。确认是重命名后摘要重点应放在行为变化而不是重复解释整份组件。CI 集成时要控制噪声。组件 Diff 摘要适合放在 PR 描述里风险项适合放在行内评论里。别把长摘要刷满 Review 页面开发者不是来读周报的。五、总结AI 组件 Diff 生成要先抽语义再写摘要。AST、Props、State、副作用和渲染分支是基础输入模型负责把结构化变化翻译成 Review 重点。组件 Diff 的目标不是复述代码而是帮助人更快判断行为有没有变坏。